[アップデート] AWS Firewall Manager ポリシースコープ内にリソースが存在する場合のみ Web ACL が作成されるよう設定出来るようになりました

いわさです。

AWS Firewall Manager を使うと、マルチアカウント環境のファイアウォールルールを一元的に管理出来ます。
先日のアップデートで Web ACL 関係の機能強化がされたとアナウンスがありました。

Firewall Manager で WAF タイプのセキュリティポリシーを作成すると、スコープ対象のアカウントに Web ACL が自動で展開されます。
今回のアップデートでは、そのセキュリティポリシーに次のオプションが追加されました。

従来はセキュリティポリシーのスコープに含まれていれば、Web ACL を使用するリソースの有無に関わらず Web ACL が自動展開されていました。
そのため、大量のアカウントに展開する際に Web ACL が不要でも展開されてしまい、無駄な料金が発生する場合がありました。

このオプションを有効化すると、スコープ内のアカウントでも対象のリソースタイプ（Application Load Balancer や API Gateway）のリソースが存在していなければ、Web ACL が展開されなくなります。結果として無駄な Web ACL が作成されなくなり、コスト削減にも繋がります。
既定で有効化されていますが、オプションをオフにして従来の挙動を行うことも出来ます。

今回はオプションを使った場合と使わなかった場合の挙動を通してどのように Web ACL が展開されるのかを紹介します。

オプション無効時はスコープ内のアカウントに自動展開されていた

セキュリティポリシーにはスコープの概念があり、組織内のどのアカウントを対象に管理するのか、どのリソースを対象にするのか、などを定義することが出来ます。
Firewall Manager は作成されたセキュリティポリシーのスコープとルールに基づいて各 AWS アカウントに Web ACL を自動作成します。

概ね期待どおりの動作ではあると思いますが、上記でいうアカウント D は将来的には必要になった際には管理したいところですが、現時点ではまだ管理対象のリソースが存在しません。
しかし、Firewall Manager によって Web ACL は作成されるので、利用料金が発生します。

この動作がこれまでの動作ですが、今回追加されたオプションを無効化することで同じ動作をさせることも出来ます。
こちらを試してみましょう。

セキュリティポリシー作成時に「Manage unassociated web ACLs」のチェックを外しておくだけです。

あとは従来どおりスコープを定義します。
今回は AWS アカウントをいくつか直接指定し、対象のリソースタイプに ALB (Application Load Balancer) を指定しました。

このポリシーが作成されると、セキュリティポリシーで構成したルールなどがスコープに指定した各アカウントへ Web ACL として展開されます。

次のように展開されていることが確認出来ました。
ちなみに、この時点ではまだ対象アカウント上へは ALB は存在していません。つまり Web ACL が作成はされていますが使われていない状態です。

今回のアップデートには関係ないですが、ポリシーの自動適用も有効化しておくことで、ALB 作成時に強制的に Web ACL をアタッチしてくれます。
この仕組みで Firewall Manager で設定したルールが、スコープ内の対象リソースタイプに適用させることが出来ます。

オプション有効化で必要なタイミングで Web ACL が作成されるように

今回のアップデートで使えるようになったオプションを有効化した場合は次のように対象リソースがアカウント上に存在しない場合は無駄な Web ACL が自動作成されなくなりました。

先程のセキュリティポリシーに対してこの機能を有効化してみましょう。
この機能は新規のセキュリティポリシーでデフォルトで有効化されていますが、既存のセキュリティポリシーに対して有効化・無効化も可能です。

対象リソースが無い状態で既存ポリシーに対して有効化すると、クリーンアップが発生する

この機能は、有効化したタイミングでスコープ内にリソースの有無を確認し、リソースが存在しないアカウントで存在する自動生成された Web ACL は削除されます。
試してみましょう。

編集から有効化しました。

先程まで、ALB が存在せずにアカウント上に Web ACL だけ作成されていたアカウントを確認してみましょう。
セキュリティポリシー変更直後はまだ Web ACL が存在しています。

クリーンアップ作業は少し時間がかかるようです。公式ドキュメントでは数時間かかると書いてありました。
私が確認した際にも待っていたのですがなかなか Web ACL が削除されずで、途中でドーナツを食べに行ってしまいました。

そして帰宅すると削除されてました。おそらく 1 ~ 2 時間かかっただろうか。

スコープにアカウントを追加する

また、上記にてセキュリティポリシー変更後にスコープへ新規アカウントを追加しました。

確認結果は先ほどのものと変わらないのでキャプチャは割愛させて頂きますが、Web ACL は作成されていませんでした。
従来はスコープとして追加したタイミングで Web ACL が作成されていたのですが、これは良いですね。

スコープリソースを追加したタイミングで Web ACL が作成される

従来作成されていた不要な Web ACL が作成されないことが確認出来ました。
では必要なタイミング、つまり ALB などスコープ対象のリソースが作成されたタイミングでどうなるのかも確認してみましょうか。

次のようにこのタイミングで始めて Web ACL が展開されるはず...！

確認方法は簡単です。ALB を作成するのみ。

少し待つと、ALB に Web ACL が関連付けされています。

AWS WAF コンソールをのぞいてみると Web ACL が無事作成されていますね。

めでたしめでたし。といきたいとことなのですが一点注意点があります。
ドキュメントによるとこのタイミングで ALB などのスコープインリソースを削除しても Web ACL は削除されないとのことです。

不要なリソースのクリーンアップは本機能を有効化した初回のみと明記されていました。常に Web ACL が最適な状態で削除されたり作成されたりするわけではないのでご注意ください。
普通に考えたら削除されそうに思えるので、混乱しそうですね。

さいごに

本日は AWS Firewall Manager ポリシースコープ内にリソースが存在する場合のみ Web ACL が作成されるように設定出来るようになったので実際に確認してみました。

基本は有効化して使うべきでしょうね。無効化する理由がちょっとわからなかったです。
小さいところですが最適なタイミングで Web ACL が自動展開されるようになりました。
これからはメンバーアカウントの多い Organizations 環境で、全アカウント WAF タイプのセキュリティポリシー設定したいんだーという場合にでもガバナンスとコスト最適化を両立出来ますね。